Web-based managed care system having a common administrative account

ABSTRACT

A web-based system for collecting and managing administrative details of a member in a managed care organization. The system collects and makes available over the Internet to all concerned parties digital information that can be selectively retrieved, viewed and managed by all authorized participants. This information, for example, includes the personal demographic details concerning the member and their eligible dependents, their plan elections and preferences, and their benefits usage history. The aggregated information is stored in a central database, using a “member account” paradigm. The member supplies the base information for the member account at initial enrollment in a health plan, either directly through the Internet or through an interface to their employer&#39;s human resources data system. Such information is then available to be shared via the Internet with a health provider, new employer or health insurance plan, or for the member themselves. Historical information about expenditures, usage, payments, and the like, can then be added to the record as experienced, allowing a greater ability to derive value from the contained information.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to a system for providing web-based data collection and management in a managed care organization.

2. Description of the Related Art

The business processes currently in place in almost all managed care organizations (MCO) are needlessly complex and inefficient, requiring a great deal of manual labor and resultant expense. FIG. 1 shows a simple example illustrating such inefficiencies. This drawing illustrates how the key constituents (members 100, employers 102 and providers 104) now carry out the simple task of making an inquiry to the MCO. As illustrated, the MCO typically provides or uses a member services call center 106, an account service call center 108, and a provider service call center 110. Data queries generated from the member services call center 106 are processed by a member services database 107, while data queries generated from account services and provider services are processed by the account service database 109 and provider service database 111. When a member 100, an employer 102 or a provider 104 desires to make an inquiry, he or she typically accesses the MCO via a telephone 115, and requested information 117 is usually returned by mail 118. Another example of the inefficiencies inherent in the current system is shown in FIG. 2, which illustrates how an employee 200 enrolls in his or her employer's managed care program. In this example, the employee 200 fills out enrollment forms 202, which are then forwarded on to the employer's HR department 204. The HR department 204 enters such data into the employer's information system 206 and then forwards the information via regular mail to the managed care organization 208. The MCO then has to enter the data in its information system 210. Such processes are time consuming and inefficient.

In addition to the structural and administrative problems inherent in the existing MCO industry, several major trends are now emerging in the health care industry as a whole. Employers are taking a less active role in the payment of and administration of health care benefits. The use of global, interconnected computer systems, such as the Internet, have become commonplace and inexpensive. Moreover, new standards, systems and processes for the health care industry infrastructure have begun to be proposed and implemented. Finally, there has been significantly increased demand by consumers for health-related information. Indeed, consumers are becoming more educated and participatory in clinical decision making and are demanding more from physicians.

The Internet has been a major catalyst for change. It is estimated that there are now over 65 million U.S. adults with access to the Internet, which represents over 25% of the population. The Internet is rapidly becoming the most important communications channel for health plans, and many companies have begun to provide health care-related services online. Healtheon Corporation provides software and services that enable healthcare information, both medical and administrative, to be exchanged over the Internet. The company provides a system to automate such tasks as HMO enrollment, referrals, data retrieval, and claims processing for use by insurers, doctors, pharmacies, and consumers. Healtheon, through WebMD, also provides Internet-based technology that connects physicians, hospitals, payors, and consumers to an array of interactive tools and services. Other companies are deploying solutions as application services. Alteer, for example, is an application service provider (ASP) that provides a web-based workflow solution to address administrative and communication needs of healthcare professionals and consumers. Alteer establishes healthcare professionals' practices as online healthcare portals. As a result, patients can visit the respective physician web sites and search for information specific to their physician's expertise and their personal needs. Other companies now provide online solutions for managing patient information access, contract compliance and billing, and clinical performance analysis. Still others provide online solutions that allow physicians to manage their clinical information and secure access to the same information by patients so that patients can actively participate in their personal family health management.

Currently, every constituent of the health care system collects a set of data that is likely to be somewhat different from one party to another. This is manifested in a health care record that is collectively strewn across the health care landscape in various multiple enterprises. The present effort of collecting each element of the data requires that the data set be as small as possible, containing only essential information. The ability to share information, such as submitting a claim to a managed care organization or authorizing a visit to a specialist, is difficult because no party can ensure that they are matching records on the same individual.

It would be desirable to be able to leverage the Internet to allow loosely-related parties to share a common set of data, with one common identification number, allowing what was previously disparate data to become meaningful, actionable information.

BRIEF SUMMARY OF THE INVENTION

The present invention is a web-based system for collecting and managing administrative details of a member in a managed care organization. The system collects and makes available over the Internet to all concerned parties digital information that can be selectively retrieved, viewed and managed by all authorized participants. This information, for example, includes the personal demographic details concerning the member and their eligible dependents, their plan elections and preferences, and their benefits usage history. The aggregated information is stored in a central database, using a “member account” paradigm. The member supplies the base information for the member account at initial enrollment in a health plan, either directly through the Internet or through an interface to their employer's human resources data system. Such information is then available to be shared via the Internet with a health provider, new employer or health insurance plan, or for the member themselves. Historical information about expenditures, usage, payments, and the like, can then be added to the record as experienced, allowing a greater ability to derive value from the contained information.

The data set which results from the present invention substantially reduces the amount of manual record-keeping that is required for each participant, while increasing data accuracy. The invention dramatically lowers administrative costs for every user of the system. In addition, data captured in the system is richer than that which is currently owned by any one party, enabling new forms of value through reporting and data extraction. The invention allows the user (whether member/patient/employee) to access their personal healthcare administrative record and use that information to increase their control over their healthcare experience. The account is portable, meaning that it will support a member's move to other employers or other health plans.

The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects and features should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the Preferred Embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and the advantages thereof, reference should be made to the following Detailed Description taken in connection with the accompanying drawings in which:

FIG. 1 illustrates how members, employers and providers obtain inquiries from existing MCO online systems;

FIG. 2 illustrates a conventional MCO enrollment process;

FIG. 3 illustrates a web-based managed care system having a common administrative account according to the present invention;

FIGS. 4A-4B illustrate representative screen displays and process flow for a member enrollment function in the web-based managed care system of the invention;

FIG. 5 illustrative representative screen displays and process flow for an employer enrollment function in the inventive system;

FIG. 6 illustrates representative screen displays and process flow for a Primary Care Physician (PCP) selection function according to the invention;

FIG. 7 illustrates representative screen displays and process flow for a benefits inquiry according to the invention;

FIG. 8 illustrates representative screen displays and process flow for downloading static pages in the system;

FIG. 9 illustrates representative screen displays and process flow for a member re-enrollment function;

FIG. 10 illustrates representative screen displays and process flow for a PCP change function;

FIG. 11 illustrates representative screen displays and process flow for a Provider Directory inquiry function;

FIG. 12 illustrates representative screen displays and process flow for Member Information Change function; and

FIGS. 13A-13C show a data entity diagram illustrating the tables that comprise the member administrative account according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Familiarity with the MCO business model is presumed in the following discussion. As is well-known, a member is a subscriber or a subscriber's dependent if the MCO accepts risk. A subscriber is an employee who is eligible and elects coverage. An employer identifies the employer entity, typically a corporation that has a contract with a health organization to provide services to its employees. The MCO is the managed care organization entity. This is the healthcare organization that is contracting with an employer entity to provide service to the employer's employees.

In an illustrated embodiment, a web-based transaction server is operated at a web site accessible over the Internet. In addition, the managed care organization (MCO) may operate a web-based transaction server (sometimes referred to herein as the MCO server or site). Typically, a user (either a member, employer, or provider) will navigate first to the MCO server and then be redirected to the transaction server, although this is not required. This configuration, of course, is merely exemplary and should not be taken to limit the present invention.

Generalizing, the invention may be practiced in any convenient server or set of servers accessible over a computer network from a client machine having a web browser or other graphics viewer. Preferably, an available resource (a document, page, object or the like) is identified by a Uniform Resource Locator (URL) that can be accessed by an authenticated user. The computer network may be the Internet, an intranet, a virtual private network, or the like. Generalizing, a server used in the present invention may be a Web Application Server (WAS), a server application, a servlet process or the like. Through the standard Hypertext Transfer Protocol (HTTP), a client browser accesses the HTTP-enabled server to obtain access to the resource. As is well-known, most browsers provide security through the Transport Layer Security (TLS) protocol. This protocol allows both the browser and the WAS to authenticate each other (i.e. to prove their identity to each other), and it also provides data protection (data integrity and data confidentiality) for data in transit between them. The strongest form of authentication provided by the TLS/SSL protocol is client- and server-side certificate authentication. Such authentication requires the client (the browser) and the server (the WAS) to each have a private/public cryptographic key pair, and associated certificates. Public key authentication maintains a binding between a user's identity and a public key that can only be unlocked by the associated private key. In an illustrative embodiment of the present invention, a client browser and a WAS implement these protocols to provide mutual authentication. Thus, the invention provides secure web-based access to protected member data which, as described below, is maintained within a novel administrative account structure.

FIG. 3 illustrates the web-based managed care system 300 having a common administrative account according to the present invention. Users of the system include members, employers, and others. The system 300 comprises a web server 302 to which users connect over a computer network 304 in a conventional manner using a client machine 306 having a web browser 308. As noted above, the network 304 is the public Internet, a corporate intranet, a private virtual network, a web content delivery service, or the like. The web server is identified by a publicly-available second level domain name. The system 300 includes a web-based subsystem 310 comprising multiplexer 312, and a set of functional modules including enrollment 314, billing 316, messaging 318, and inquiry 320. Each module interfaces to a transaction processor 322 and a database 324. The transaction subsystem interfaces to the managed care organization (MCO) subsystem 330 through a set of common XML-based interfaces 326 and 328. The MCO subsystem 330 is accessible through an MCO server 332 and includes a transaction processor 334 and a backend database 336.

Each of the functional modules is accessible via a web browser. Collectively, these modules comprise an administrative toolset that leverages off-the-shelf technology to fundamentally change how these administrative processes are carried out in a managed care organization. In an illustrative embodiment, the enrollment module 314 enables members, employers and providers to enroll, re-enroll, and to view enrollment information. More specifically, the enrollment module provides the following major functions: group account setup, eligible employee roster upload, member enrollment and changes, employer validation, notification, reporting, online help, and temporary ID card provisioning.

The billing module 316 enables online billing and payment, and facilitates claims matching. By leveraging the information about who is enrolled through the use of a roster which is shared between the employer and the plan, a great deal of manual work can be eliminated. Currently, each party must reconcile their rosters to the other's manually. The billing module allows the importation of a roster file from either party, and execution of a “compare roster” function within the module reports on any differences between the two. The shared roster leads to more accurate bills. In particular, the bill is presented via the secure messaging module 318, eliminating time and postal waste. The bill, which is preferably presented via XML, includes “drill down” capability for detail inquiries, and an Electronic Funds Transfer component to facilitate immediate payment.

The messaging module 318 provides secure messaging among the various parties to enable referrals, authorizations, reporting and the like. The use of electronic communication by non-secure means such as standard e-mail is rising, and Health Insurance Portability and Accountability Act of 1996 (HIPAA) guidelines will require a more robust solution. The messaging module allows users to communicate with other selected parties in their personal healthcare network, such as a patient to their Primary Care Physician, a PCP referring to a specialist, or from any constituent to the MCO. The recipient is notified that a secure communication is waiting to be read on the host server, and only after a secure sign-on process (where the user is identified) can he or she read that information. The message preferably is never exposed to non-secured channels.

The inquiry module 320 provides a mechanism for provider database lookup, viewing of enrollment information, and the like. This module provides a solution to one of the biggest sources of constituent frustration in the healthcare industry—the ability to easily get answers to questions. The inquiry module provides a self-service solution for the user to find the answers they need to the most common types of questions: Claims Status, Eligibility and Benefits Inquiry, Provider Network information, and access to FAQ documents that are custom tailored by the application for that particular user. In a preferred implementation, each module uses Common Gateway Interface (CGI) fill-in forms or active server pages (.asp) to obtain data that is managed by the system, as will be seen.

FIGS. 4A-4B illustrate the representative screen displays and process flow for a typical member enrollment. This functionality is provided by the administrative toolset and, in particular, by the enrollment module 314. The process begins when the user navigates to the MCO home page 400 hosted on web server 332. When the user selects the Enroll Now link, the user is redirected to the enrollment page 402 hosted on web server 302. To enroll, the user selects the login link, which opens the browser to an enrollment overview page 404 describing an overview of the enrollment process and the information that the user will need to provide to complete the enrollment process. Upon selection of the Next link, the browser opens up an Employer ID# page 406. This page requires entry of an Employer ID and Division ID provided to the user by the employer. Upon entry of this information, the user selects the Next link, which opens a Choose Coverage Type page 408. This page identifies the possible coverage types (e.g., individual, 2 person, family, or the like) that are available from the MCO. Each coverage type is a hypertext link. Selection of one of the links (in the case, the Individual link) opens the browser to Coverage Information page 410, which describes the relevant coverage. When the user selects the Next button, the browser returns to the Choose Coverage Type page 408.

If the user selects the Next button from the Choose Coverage page 408, the browser opens a Subscriber Information page 412, which includes a fill-in form requesting personal details about the subscriber including, for example, name, title, address, telephone, fax, email, etc. The form also requests the user to identify whether he or she is covered under another health plan. If so, the plan benefits will need to be coordinated if they are not already. Thus, once the form is filled-in and the user selects the Next button, a test 414 is executed to determine whether the user is covered by another plan but the system has not coordinated benefits. If the outcome of the test at step 414 is positive, the browser opens up a Coordination of Benefits page 416, which requests the user to identify his or her other plan by name and plan subscriber. The user then selects the Next button, which executes a test at step 418 to determine whether the plan subscriber is a subscriber to the MCO plan or, alternatively, a family member. If the outcome of the test at step 418 indicates that the plan subscriber is the subscriber, the browser navigates back to the Subscriber Information page 412. If, however, the test at step 418 indicates that the plan subscriber is a family member, the browser is directed to a Family Member Information page 422 as will be described below.

If the outcome of the test at step 414 is negative, however, the user is navigated to a Family Summary page 420. This page lists each member of the MCO subscriber's family. By selecting a Details button next to each name, the user can navigate to a Member Details page 424 and then return back to the Family Summary page 420. By selecting a Change Button in page 420, the user is navigated back to the Subscriber Information page 412. By selecting a Remove Button in page 420, the browser opens up a pop-up window 426 requesting confirmation. A test 428 is then run to determine whether a person is to be removed. If so, the browser returns to the Family Summary page 420 with the selected person removed. If, however, the outcome of the test at step 428 is negative, the browser returns to the Family Summary page 420 without change.

The user may select the Add Another Family Member button in page 420, which opens the browser to the Family Member Information page 422. This page requests relevant information such as name, title, address, telephone, fax, email, DOB, SSN, relationship, primary language, and the like. As noted above, this page is also reached from the test at step 418. The Family Member Information page also questions whether the member is covered under another plan and if the member is a full-time student over 18. When the user selects the Next button on page 422, a test is run at step 430 to determine whether the coordination of benefits box was checked and not filled in. If so, the browser returns the Coordination of Benefits page 416, which has been previously described. If, however, the outcome of the test at step 430 is negative, a test is executed at step 432 to determine if the student button was selected and not filled in. If not, the browser returns to the Family Summary page 420. If, however, the outcome of the test at step 432 is positive, the browser navigates to the Enter Student Info page 434 so that data (e.g. school name, city, etc.) can be collected. From Enter Student Info page 434, selection of the Next button returns the browser to the Family Summary page 420.

When the user selects the Complete button on the Family Summary page 420, the browser returns a Choose a Plan page 436. This page identifies specific plan types (e.g., HMO, PPO, or the like), each of which is identified by a hypertext link. When the user selects a plan link, the browser opens up the appropriate description page, in this case the HMO Plan Information page 438. If the user selects the Next button from the Choose a Plan page 436, a test is performed at step 440 to determine whether the selected plan requires a Primary Care Physician (PCP) selection. If so, the browser navigates to PCP Selection page 442. This page enables each family member to select a given PCP or, using a Select All button, to force each family member's PCP to be the same as the subscribers. If the Select PCP button is selected, the browser navigates to a PCP search page 444, which is described in more detail below. When the user selects the Next button from the PCP Selection page 442, or upon a negative outcome of the test at step 440, the browser opens a Disclaimer page 446 setting forth the legal terms and conditions for enrollment. If the user selects the “I Agree” button, the browser navigates to a Thank You page 448. If the user selects the “I Disagree” button, the browser navigates to an Are you sure page 450 requesting whether the user desires to cancel enrollment. From the Thank you page 448, the user can print an Enrollment Confirmation page 452 or return to the MCO home page. This completes the enrollment process.

FIG. 5 illustrates a representative employer enrollment process. In this case, the user navigates to the MCO home page 500 and selects the Enroll Now button. This navigates the user's browser to the system employer login page 502. By selecting the Login button, the user navigates to the Employer Main Menu page 504. Selection of the View Roster button returns a View Current Roster page 506, which identifies the current employees of the company. By selecting a Details button next to each name, the browser navigates to an Enrollee Details page 508, which identifies the employee and his or her family member data. By selecting a Click to Download button on page 506, the browser returns a Download Current Roster page 510, which includes appropriate roster links as shown. From the Verify New Enrollee button in page 504, the browser navigates to an Approve or Deny New Enrollee page 512. From that page, the user can verify that an identified enrollee is eligible for the plan by highlighting an entry and selecting the Submit button. After all entries are checked, as determined by a positive outcome of the test at step 514, control routines the browser to the Employer Main Menu page 504. The user can then logoff or perform other tasks.

FIG. 6 illustrates a representative PCP Selection process, which can occur from enrollment, re-enrollment or PCP Change processes. From the PCP Selection page 600, the user navigates to the Search for a Physician page 602. The user can fill in parameters such as name, address, gender, language, hospital affiliation, medical group affiliation, type of plan, specialty, and the like. After selecting the Submit button, the search engine returns a Search Results page 604, which identifies one or more matching selections based on the search criteria. A test is then performed at step 606 to determine whether the PCP's Panel is open for additional patients. If not, a Search Results page 608 is returned to the user indicating that the physician cannot accept additional patients and requesting selection of another physician. If the outcome of the test at step 606 is positive, however, the Search Results page 610 is returned identifying the particular physician.

FIG. 7 illustrates a representative operation of the benefits inquiry module. The routine begins when the user navigates to the MCO home page 700. A user can select the Members button, the Employers button or the Providers button. Depending on the button selected, the user is navigated to the appropriate login page 702 of the system. Upon selection of the Login button, an Account page 704 is returned to the browser. Selection of a Benefits Coverage Inquiry button returns a Patient Search page 706. Following entry of the requested information and selection of the Submit button, a Search Results page 708 is returned if the member is found. This page identifies the member, the provider, co-pay information and other coverage details. If the member cannot be found, another Patient Search page 710 is returned. If the member cannot be located after a given number of attempts, a Patient Search page 712 is returned indicating that the patient could not be located given the search criteria entered. This completes the benefits inquiry process. A similar functionality is provided to inquire about a given provider.

FIG. 8 illustrates the process flow and display screens for downloading static pages. This function may also be provided by the inquiry module. The routine begins with the user navigating to the MCO home page 800 and then to the system login page 802. Upon login, the Account page 804 is returned. Upon selection of the Printed Materials button, the routine tests to identify what document has been selected from the access database 806. An appropriate Document Listing Page 808 is then returned to the browser. Once the user selects the document to be printed, the browser retrieves the appropriate HTML form 810. A read-only version 812, e.g., in .pdf format, may be retrieved by selecting a button in the HTML page.

FIG. 9 illustrates screen displays and illustrative process flow for a member re-enrollment function. The routine begins with the user navigating to the MCO home page 900 and then to the system login page 902. Upon login, the Account page 904 is returned. Upon selection of the Re-enroll button, the Subscriber Information page 912 is returned. From this point forward, the enrollment functionality is similar described above with respect to the screens that are common to FIGS. 4A-4B.

FIG. 10 illustrates screen displays and illustrative process flow for a PCP change function. The routine begins with the user navigating to the MCO home page 1000, to the system login page 1002, and then to the Account page 1004. From this screen, the user selects a Change a PCP button. As a result, the PCP Selection page 1006 is returned. This function was described previously in FIGS. 4A-4B.

FIG. 11 illustrates screen displays and illustrative process flow for a Provider Directory inquiry. The routine begins with the user navigating to the MCO home page 1100, to the system login page 1102, and then to the Account page 1104. Upon selection of a Search Provider Directory button, the browser navigates to a Search For A Physician page 1106. This functionality was described above in FIG. 6.

FIG. 12 illustrates screen displays and illustrative process flow for a Member Information Change function. The routine begins with the user navigating to the MCO home page 1200, to the system login page 1202, and then to the Account page 1204. Upon selection of an Update My Information button, the browser navigates to a Family Summary page 1206. This page was previously described in FIGS. 4A-4B. If the Add Another Family Member button is selected, a test is run at step 1208 to determine if the change happens during an open enrollment period. If so, the browser returns the Member Information page 1210 as previously described in FIGS. 4A-4B. If, however, the outcome of the test at step 1208 is negative, the browser returns a Qualifying Event page 1212, which indicates that the user has requested a change outside of his or her open enrollment period. In such case, the user selects the appropriate Qualifying Condition button, and the browser returns an Affidavit page 1214 to allow the change to be processed.

According to a feature of the present invention, a novel account structure is used to manage administrative transactions (e.g., enrollment, changes, inquiries, claims, benefits, etc.) across multiple plans. The account comprises a linked set of data tables that are organized into a logical entity in a database stored in memory or permanent storage. The database is then accessible to the web-based managed care transaction system. As a user moves from one job to another, or as a given plan is changed or replaced, the user's past history remains persistent and accessible from the account. Thus, the account provides a complete member history that is persistent across plan changes, employment changes, family history changes, and the like. The account allows members the opportunity to review and manage the many aspects of their personal care through a web browser. As will be seen, the account includes a record of the member's healthcare benefits throughout their life.

The account, called ACCOUNT in an illustrative embodiment, is shown in the data entity relationship diagram of FIGS. 13A-13C. Each block in this diagram is a table that includes a number of attributes. A particular table may have a 1:1 or a 1:many relationship to another table. Thus, for example, the master account (ACCOUNT table 1300) has a 1:1 relationship to the MEMBER table 1302 because each account has only one member associated therewith. The MEMBER table 1302 has a 1:many relationship with MEMBER HISTORY table 1304 as a given member may have a history of involvement with more than one health plan.

Each of the tables is described generally below:

ADDRESS USER 1306—is the generic address participation matrix identifying a user type (members, PCPs, employers) to possible purposes (home, work, mailing, billing, etc.);

ASSIGNED PCP 1308—is the selected Primary Care Physician for a member enrollment period;

CLAIMS INFO 1310—includes all claims-related information;

COORD BENEFIT 1312—identifies the coordination benefits for the member;

DIGITAL ADDRESS 1314—identifies the electronic and/or digital contacts for an individual;

EMPLOYER 1316—identifies the employer entity, typically a corporation that has a contract with a health organization to provide services to its employees;

EMPLOYER PLAN 1318—identifies the various plans that the Employer group has contracted with an MCO. The data includes Group Number, Division Number, Employer Plan ID, and a selected MCO Product/Plan is part of the designated health plan offering to the employee;

EMPLOYER STAFF 1320—identifies what users of the Employer group are allowed access to the system via an account setup process;

ACCOUNT 1300—is the account setup information that contains userID/password and helpful things to login and use the secured site;

LOOKUP 1322—is a lookup table for allowable values for a table/column_lookup_key combination in the schema;

HOSPITAL AFFILIATION 1324—is a table that identifies all hospital affiliations associated for this particular provider;

MCO 1326—is the managed care organization entity. This is the healthcare organization that is contracting with an Employer Entity, thus providing service to the Employer's employees;

MCO PRODUCT 1328—is a table listing plans or products that are provided by a health care organization;

MCO STAFF 1330—is a table that identifies what users of the managed healthcare group are allowed access to the system via the account setup process;

MEMBER 1302—is a table that identifies personal data for each member;

MEMBER HISTORY 1304—is a table that describes the participation history of a member. This table identifies the relationship and history of what healthcare plan the member has enrolled in all companies for which he or she worked;

MEMBER STUDENT 1332—is a table identifying information about the school and location if the member is a fulltime student;

ORG INFO 1334—is a table that is relevant if the provider in the PROVIDER INFO table is identified as an organization provider;

PHYSICAL ADDRESS 1336—is a table identifying actual physical addresses that can be associated to anyone or any corporation;

PROVIDER AFFILIATION 1338—is a table that provides the intersection information of a provider practicing what allowable specialties at a practice site;

PROVIDER INFO 1340—is a table describing the provider selected by the member;

PROVIDER LANG 1342—identifies all languages in which this provider can communicate with his or her patient;

PROVIDER SPECIALTY 1344—identifies all specialties practiced by this provider;

PROVIDER STAFF 1346—identifies all staff members to a particular provider who require access to the system via the account setup process;

SITE SPECIALTY 1348—is an intersection table to show a provider's specialties that are practiced at a particular site;

STAGING AREA 1350—is a table that tracks the process of a member through the system for various transaction events, e.g., enrollment, profile change, or the like;

STAGING AUDIT 1352—is an audit log for a specific record;

STAGING DIGITAL ADDR 1354—is a table that contains other digital addresses that are related to this particular Staging Area record; and

STAGING PHYSICAL ADDR 1356—is a table that contains other physical addresses that are related to this particular Staging Area record.

The following is a detailed Data Dictionary for each of the above tables, with each attribute identified by name and description.

Attribute Entity Name Entity Description Name Attribute Description PK Req FK ADDRESS USER This is the generic Purpose Cd This identifies the No Yes No Address participation purpose of this matrix identifying a address; such as: user type (members, “1. PR = Practice pcp's, employers) to Address” “2. HM = possible purposes Home Address” “3. BL = (home, work, mailing, Billing Address” billing, etc.). “4. ML = Mailing Address” “5. WK = Work Address” User Cd The identifies the No Yes No user types of this address matrix. Supported types may include: “1. MEM = Member” “2. MCO = MCO” “3. EMP = Employer Group” “4. PPS = Provider Practice Site” Digital Unique type No No Yes Address Key identifier of digital address. Employer Key Unique lookup key No No Yes that identifies this employer coverage based on a contract number with a MCO. MCO Key Unique managed care No No Yes identifier key. Member Key This identifies a No No Yes unique Member; currently based on Social Security Number and Date-Of- Birth. Physical Unique record No No Yes Address Key identifier of this address. Practice Site This key uniquely No No Yes Key identifies a practice site for a provider. This practice details the MCO product that is provided by this doctor. AMI Addr Who This is a placeholder No No No attribute used by the AMISYS source load group. ASSIGNED PCP This is the selected History Key This is a unique No Yes Yes Primary Care reference key to a Physician for a specific member member enrollment working for a period. specific employer enrolled in a specific plan for a specific enrollment period. Basically, add Start Date, Coverage Type, Group/Division Id, and Employer Plan Id to the specified list of foreign keys. Practice Site This key uniquely No Yes Yes Key identifies a practice site for a provider. This practice details the MCO product that is provided by this doctor. First Name Provider's first name No Yes No Last Name Provider's last name. No Yes No Start Date Start date of this No Yes No PCP for this member's span. Provider Num A provider number No No No recognized by a particular MCO. For example, this relates to the PROV# field in ANISYS. Site Cd A term identifying No No No the Site Code of the group practice that the physician belongs to. CLAIMS INFO FUTURE . . . A generic Claims Reference Key Yes Yes No cut at all relevant claims related information. Site A unique identifier No Yes Yes Specialty Key based on all of a provider's specialties at this site. Member Key No Yes No Affiliation Fund Amt No No No Attending Local Risk Unit No No No Attending Provider Key No No No Attending Sub Risk Unit No No No Authorization Num No No No Billed Amt No No No Claim Adjustment Amt No No No Claim Payment Date No No No Claim Status No No No Claim Type Cd No No No Coinsurance No No No Amt Copay Amt No No No Deductible No No No Amt Diagnosis 1 Service Line No No No Diagnosis 2 Service Line No No No Discharge No No No Status Fee For Service Amt No No No Financial Service Type No No No ICD 9 Num No No No Medicare Payment Amt No No No Paid Amt No No No PCP Local Risk Unit No No No PCP Provider No No No Key PCP Sub Risk Unit No No No Pool Name No No No Primary Insurance Cd No No No Procedure No No No Desc Referring Local Risk Unit No No No Referring Provider Key No No No Referring Sub Risk Unit No No No Risk Withheld Amt No No No Service End No No No Date Service Start No No No Date Servicing Local Risk Unit No No No Servicing Provider Key No No No Servicing Sub Risk Unit No No No TPP Amt No No No COORD BENEFIT This is the History Key This is a unique No Yes Yes coordination of reference key to a benefits for the specific member member. Shared cost working for a to another insurance specific employer group enrolled in a specific plan for a specific enrollment period. Basically, add Start Date, Coverage Type, Group/Division Id, and Employer Plan Id to the specified list of foreign keys. Start Date Start date of this No Yes No COB coverage. Birthdate Birthday of the No No No associated subscriber providing this additional coverage term. Carrier Name Name of the No No No additional insurance coverage provider. Coverage Type The coverage type of No No No this policy; i.e. Self, Spouse, Dependents, Medicare, Medical, Dental, etc. Effective The effective date of No No No Date this secondary policy. First Name First name of No No No subscriber to this secondary policy/plan. Last Name Last name of No No No associated subscriber to this additional plan. Policy Num Insurance policy No No No number for this coordinate benefit. DIGITAL This is the Digital Unique type Yes Yes No ADDRESS electronic and/or Address Key identifier of digital digital contacts for address. an individual. Type Cd This code defined the No Yes No various types: “1. VC = Voice/Land phone” “2. CL = Cell phone” “3. PG = Pager” “4. EM = Email” “5. WB = Web HomePage” Value1 Contains initial No Yes No value associated with a type of digital address. For example - voice mail includes: 800.555.1212 or abc@foobar.com for Email type. Value2 This may be a second No No No value set to a specific type of digital address. For example - voice mail may include an extension part to the original phone number. Value3 This third value No No No association is for obscure elements like answer back string to a modem connect and/or future electronic requirements. EMPLOYER This is an employer Employer Key Unique lookup key Yes Yes No entity; it identifies that identifies this an corporation (i.e. employer coverage General Electric) based on a contract that has a contract number with a MCO. with a health organization to provide services to its employees. Company Name Name of an Employer No Yes No contracting with a MCO for services for its employees. For example, General Electric. Logo1 URL Location of primary No No No employer graphical logo. Logo2 URL Location of secondary No No No employer graphical logo. EMPLOYER PLAN This identifies the Employer Plan This uniquely Yes Yes No various plans that Key identifies a the Employer group particular plan that have contracted with an Employer Group is a MCO. Group number, providing for its Division number, employees. Employer Plan id, and a selected MCO Product/Plan is part of the designated health plan offering to the employee. Employer Key Unique lookup key No Yes Yes that identifies this employer coverage based on a contract number with a MCO. Participation This identifies a No Yes Yes Key specific product that a health care organization will provide for service to any employer groups. Employer Plan This is the employer No Yes No Id plan id; it should uniquely identify the Employer to a Contract Id for a certain SubGroup (Group/Division) that it expect healthcare coverage from a MCO. This identifier will be a generated value; format = TBD. Sub GroupId This is the Employer No Yes No group number that is known to the health care provider. For example, Union and Non-Union are two different subgroups under a single employer plan with a MCO. Tier Type Tier Type that is No Yes No associated with this Employer/MCO contract/plan. This value is derived from the same source that provides for the Sub Group Id. For HHPC, the various Tier Types (Value field in LOOKUP) are: 1. “02” 2. “03” 3. “04” 4. “05” 5. “06” 6. “7” 7. “3S” 8. “ME” 9. “MR” 10. “SP” Note that tier types drive what coverage/contract types are allowed for this particular plan - i.e. Single; Family; etc. For example, in the corresponding LOOKUP table, “I” will populate the Short_Desc field; and “Individual” will populate the Long Desc field. Open Enroll Identifies the end No No No End Date date for open enrollment for this particular plan/sub group. Open Enroll Identifies the start No No No Start Date date for open enrollment for this particular plan/sub group. Sub Group Identifies the No No No Effective effective date for Date enrollment allowed by this particular plan/sub group. Sub Group This field will No No No Text enable a textual description of the associated SubGroupid; if SubGroupid is a pure numeric value. For example, uses SubGroupId values like: 066131000; this represents the Group/Division number. Waiting Identifies the No No No Period Days waiting period that is required by this plan/sub group for the member applicant. EMPLOYER This table identifies Employer Key Unique lookup key No Yes Yes STAFF what users of the that identifies this Employer group are employer coverage allowed access to Web based on a contract Server via the number with a MCO. account setup process. Admin Role This identifies the No Yes No particular role that the system allows the Employer group to control what security levels to access what part of the database. Acct Key This is unique Key No No Yes based on Username. First Name First Name of No No No Employer group user. Last Name Last name of Employer No No No group user. SSN Social security No No No number to uniquely identify the user. ACCOUNT This is account setup Acct Key This is unique Key Yes Yes No information. It will based on Username. contain username/password and “helpful” hints to login and use secured site. Effective The effective start No Yes No Date date that this account will be active. Password Account user's chosen No Yes No PASSWORD Username Account member's No Yes No chosen USERNAME. End Date The effective end No No No date of this HBK account. Hint Answer This is the user's No No No specific answer to the above Hint Question; it should correspond to the user defined question. If the user types in the correct answer, the assigned Password to the Username is displayed, and the user can try login on again. Hint Question This is user defined No No No question that the user can designate as an alternate way of logging into the system. For example: “What's my favorite color?” Login Attempt This is a counter No No No Cnt that reflects the number of times the user is trying to log into the system. Modified By Audit purpose to No No No capture who last modified this record. Modified Date Audit purpose to No No No capture the last modified date of this record. Role Type Cd This is a place No No No holder attribute for future releases of the system. Role Type can further define a Username within the system into either a Member or Provider role type. For example, a Member who is also a Provider can have the same login Username; role type can differentiate what classification the user wants to be. Status The status of the No No No user login session. LOOKUP This is a lookup Lookup Key This uniquely Yes Yes No table for allowable identifies a values for a table/column/value table/column_lookup_key combination. combination in the schema. Note that the foreign key - MCO_Key - is optional in this table; if the set of lookup values is generic across all MCO's, then this field is NULL; otherwise a specific MCO set of lookup values will have field pointing to the specific MCO. Column Key The column key name No Yes No Name for the specified table. For example, the table - MCO_PRODUCT - has a column called Plan_Cd_Lookup_Key. So the Column_Key_Name in this LOOKUP table will be “Plan Cd”. Table Name The table name in No Yes No schema. Value Actual value returned No Yes No for the table/column combination. For example, in MCO_PRODUCT table - for column Plan_Cd - a possible value can be ‘IH’; which stands for Integrated HMO Product. MCO Key Unique managed care No No Yes identifier key. Long Desc No No No Seq Num Allows for ordering No No No of values. Short Desc No No No HOSPITAL This table identifies Provider Key An internal unique No Yes Yes AFFILIATION all hospital provider identifier. affiliations associated for this particular provider. Hospital This is internal No Yes No Provider Key unique provider key that identifies the hospital as the Organization provider. Look at ORG_INFO table for organization type of a hospital facility. Primary Future . . . A ‘Y’es or No No No Affiliation ‘N’o indicator; it Flg identifies whether this hospital is the primary facility for this provider to treat patients. MCO Managed Care MCO Key Unique managed care Yes Yes No Organization Entity. identifier key. This is a healthcare organization that is contracting with an Employer Entity; thus providing service to the Employer's employees. Organization Name of managed care No Yes No Name organization. Logo1 URL Location of primary No No No MCO graphical logo. Logo2 URL Location of secondary No No No MCO graphical logo. MCO PRODUCT This is the list of Participation This identifies a Yes Yes No plans that is Key specific product that provided by a health a health care care organization. organization will Plans and products provide for service are synonymous in to any employer meaning. groups. MCO Key Unique managed care No Yes Yes identifier key. Plan Cd Contains the No Yes No Lookup Key appropriate Lookup Key in LOOKUP table for Plan Cd. See definition of Plan Cd field. This is the plan code or name that is offered by the MCO. PCP Select This identifies No No No Flg whether a product requires a PCP selection. Allowable values will be ‘Y’ or ‘N’. Plan Detail This points to a web No No No URL page for the description to this product/plan code. MCO STAFF This table identifies MCO Key Unique managed care No Yes Yes what users of the identifier key. Managed Healthcare group are allowed access to the system via the account setup process. Admin Role This identifies the No Yes No particular role that the system allows the group to control what security levels to access what part of the database. Acct Key This is unique Key No No Yes based on Username. First Name First name of this No No No MCO-based user. Last Name Last name of the MCO- No No No based user. SSN Social security No No No number to uniquely identify this MCO- based user. MEMBER This table identifies Member Key This identifies a Yes Yes No any member. unique Member; currently based on Social Security Number and Date-Of- Birth. Birthdate Date of birth of this No Yes No member. First Name First name of this No Yes No member. HBK Acct Flg This flag condition No Yes No shows that the member has a username/password account already. It is a Yes/No condition. Last Name Last name of this No Yes No member. Relation Cd This field indicates No No No the relationship of member to the primary subscriber of plan. Current Relation Code recognized are: 01 = Self 02 = Spouse 03 = Unmarried child under 19 04 = Unmarried stepchild under 19 05 = Unmarried fulltime student over 19 06 = Handicapped 07 = Ex- Spouse SSN US-based Social No Yes No Security Number. Subscriber This identifies a No Yes No Member Key plan's subscriber; the primary and known employee to the employer group. The idea is that dependant member will always point back to the plan's primary subscriber id. If Member Key = Subscriber Member Key, then this record identifies the primary plan member. Acct Key This is unique Key No No Yes based on Username. COB Flg A Yes/No flag No No No indicator to identify if this member have the additional COB coverage. Gender This is a single No No No character column; note that this is an optional field: 1. M = Male 2. F = Female Hiredate This is the hiring No No No anniversary date of the member to the employer group that he/she belongs to. Language Cd The language code No No No that is preferred by this member. For example, 1. AS - American Sign Language 2. CA - Cantonese 3. EN - English 4. IT - Italian 5. SP - Spanish etc. Member Num This is a place No No No holder for a member id/number that can uniquely identify this member to the system. For example, assigned Member# will be used here; i.e. HP12346700 for the subscriber member and HP12346701 for a spouse to this subscriber. Note that this field will be NULL; if a complete new member enrollment. The expectation is that the MCO will assign this member a number once the request goes through the normal business process. Middle Name Middle name of this No No No member. Prefix The relates to what No No No the member wants to be addressed with; i.e. Mr, Ms, Mrs, Dr, etc. Student 19 If member is a No No No Flg student over 19, require additional information. A ‘Y’es or ‘N’o indication is required. Suffix This relates to what No No No the member wants to be addressed with at the end of his name; i.e. Paul Williams III - John Smith, ESQ. MEMBER This entity describes History Key This is a unique Yes Yes No HISTORY the participation reference key to a history of a member. specific member It will show the working for a relationship and specific employer history of what enrolled in a healthcare plan he specific plan for a has enrolled in all specific enrollment companies that he had period. Basically, worked for. add Start Date, Coverage Type, Group/Division Id, and Employer Plan Id to the specified list of foreign keys. Employer Plan This uniquely No Yes Yes Key identifies a particular plan that an Employer Group is provider for its employees. Member Key This identifies a No Yes Yes unique Member; currently based on Social Security Number and Date-Of- Birth. Coverage Type The parameters to No Yes No Lookup Key LOOKUP table will be based on the type of healthcare coverage that the member is subscribing to: 1. I = Individual, 2. F = Family, 3. etc. Note that the various Coverage Types are different; depending on the Tier Type (in EMPLOYER_PLAN table) that is associated with Plan/Contract/Sub Group Id. End Date Effective end date of No Yes No this member's participation in healthcare coverage. Start Date Effective start date No Yes No of this member's participation in healthcare coverage. Member Num This field is No No No captured for historical purposes only; the data should be read from the active Member Num during this enrollment span. This is a place holder for a member id/number that can uniquely identify this member. For example, assigned Member# will be used here; i.e. H212346700 for the subscriber member and HP12346701 for a spouse to this subscriber. Note that this field will be NULL; if a complete new member enrollment. MEMBER If a member is a History Key This is a unique No Yes Yes STUDENT fulltime student over reference key to a 19, require specific member information of the working for a school and its city specific employer and state. enrolled in a specific plan for a specific enrollment period. Basically, add Start Date, Coverage Type, Group/Division Id, and Employer Plan Id to the specified list of foreign keys. School City The City where the No Yes No school is located. School Name Name of school where No Yes No the fulltime student is enrolled. Start Date Start date of this No Yes No school of Fulltime Student member. Graduation The expected No No No Date graduation date for member from this school. School State The state where the No No No school is located. School ZIP Postal zipcode of No No No school. School ZIP Long postal zipcode No No No Plus4 of school. Semester End The end date of No No No Date member's school semester. Semester The start date of No No No Start Date member's school semester. ORG INFO This table is only Provider Key An internal unique No Yes Yes relevant if the HBK provider Provider in PROVIDER identifier. INFO table is identified as an organization provider. Since Organization Provider is a non person; a different set of data is kept; for example, legal corporate name; a tax id; etc. Legal Name A full legal name of No Yes No this organization; i.e. Mass. General Hospital. Type Cd Future . . . This type No Yes No code classifies what organization type is this org. provider; i.e. Facilities - Hospitals; Group Practices; etc. Site Cd The Site Cd to No No No identify this organization provider. Tax Id Future . . . This is the No No No legal tax identifier for this org. provider. PHYSICAL The actual physical Physical Unique record Yes Yes No ADDRESS addresses that can be Address Key identifier of this associated to anyone address. or corporation; i.e. Mailing, Home, Work, etc. Address Line1 Address line 1 No Yes No containing the typical information of: 123 Main Street City City name of physical No Yes No address, Country A recognized Postal No Yes No Country Code. County County name of No Yes No physical address. State State where physical No Yes No address is based. ZIP US based postal zip No Yes No code. Address Line2 Address line 2 No No No containing typical information regarding: P.O. Box; Suite#; Apt#; etc. ZIP Plus4 The longer version of No No No US-based postal zip code. PROVIDER This table provides Practice Site This key uniquely Yes Yes No AFFILIATION the intersection Key identifies a practice information of a site for a provider. provider practicing This practice details what allowable the MCO product that specialties at a is provided by this practice site. doctor. Participation This identifies a No Yes Yes Key specific product that a health care organization will provide for service to any employer groups. Provider Key An internal unique No Yes Yes provider identifier. Provider Num An provider number No Yes No recognized by a particular MCO. Site Cd A term identifying No Yes No the Site Code to the group practice that the physician belongs to. Accept New A conditional flag No No No Flg (Yes/No) to indicate whether a provider is accepting new patients at this particular practice site. AMI PlanCd This is a placeholder No No No attribute used by the AMISYS source load group. Effective This effective start No No No Date date for this relationship between MCO and Provider. IRS Tax Id Tags each affiliation No No No with a Tax Id or SSN. This is tied to the how each provider at each site may have a different tax id for claims payment. Primary Indicates whether No No No Practice Site this site is a Flg primary practice site for this provider. FUTURE . . . This field may belong in SITE SPECIALITY if we need to track primary practice site at a provider's specialty level. Site Review This indicates what No No No Status the site review status for the provider's specialty at this practice site. FUTURE . . . This field may belong in the SITE SPECIALTY table if site review is tracked on the specialty level at a practice site for a provider. Term Date The termination date No No No for this relationship between MCO and Provider. PROVIDER INFO A table describing Provider Key An internal unique Yes Yes No the Provider; if a provider identifier. person, then information like SSN; Last and First Name; Gender; etc. This demographics type information is useful to selection by members. Note: if provider is a non- person, then the ORG INFO table will contain equivalent corporate information like: Legal Name; Tax Id; etc. Org Flg A flag to indicate No Yes No whether this provider is an individual Clinician/Provider or an organization like: hospital; group practices, etc. A 'Y'condition will force a lookup for name; tax id; site codes in the ORG INFO table. AMI Provider This is a placeholder No No No Num attribute used by the AMISYS source load group. Birthdate Birthdate of this No No No Clinician provider. First Name First name of this No No No Clinician provider. Gender This is a single No No No character column; note that this is an optional field: 1. M = Male 2. F = Female Last Name Last Name of this No No No Clinician provider. Logo1 URL A primary pointer to No No No a graphical logo for this physician provider. Logo2 URL A secondary pointer No No No to a graphical logo for this physician provider. Middle Name Middle name of this No No No Clinician provider. SSN Social Security of a No No No Clinician provider. PROVIDER LANG All languages that Provider Key An internal unique No Yes Yes this provider can HBK provider communicate with his identifier. patients in. Language Cd Contains the No Yes No Lookup Key appropriate Lookup Key in HBK_LOOKUP table for Language Cd. See definition of Language Cd field. The language code that this particular provider is fluent in. For example, 1. AS - American Sign Language 2. CA - Cantonese 3. EN - English 4. IT - Italian 5. SP - Spanish etc. PROVIDER This table identifies Prove Spec Uniquely identifies a Yes Yes No SPECIALTY all specialties Key specialty code to practiced by this this provider. provider. Provider Key An internal unique No Yes Yes provider identifier. Specialty Cd Contains the No Yes No Lookup Key appropriate Lookup Key in LOOKUP table for Specialty Cd. See definition of Specialty Cd field. An industry set of specialties that can be practiced by a provider. Credential Future . . . A ‘Y’es or No No No Flg ‘N’o flag indicating that this specialty requires Credentialing or not. PCP Allowed Future . . . A ‘Y’es or No No No Flg ‘N’o indicator identifying whether the specialty allows for PCP designation. PROVIDER This table contains Provider Key An internal unique No Yes Yes STAFF all staff members to provider identifier. a particular provider who requires access to the system via the account setup process. Admin Role This identifies the No Yes No particular role that allows a Provider to control what security levels to access what part of the database. Acct Key This is unique Key No No Yes based on Username. First Name First name of this No No No Provider group user. Last Name Last Name of Provider No No No group user. SSN Social security No No No number to uniquely identify the user. SITE An intersection table Site A unique identifier Yes Yes No SPECIALTY to show a provider's Specialty Key based on all of a specialties that is provider's practice at a specialties at this particular site. site. Practice Site This key uniquely No Yes Yes Key identifies a practice site for a provider. This practice details the MCO product that is provided by this doctor. Prov Spec Key Uniquely identifies a No Yes Yes specialty code to this provider. STAGING AREA This table tracks the Tran Key This is unique Yes Yes No process of a member identifier for this through the system particular Staging for various Area record. transaction events; i.e. Enrollment; Profile Change; etc. Birthdate Birthdate of this No Yes No effected member. Tran Id This transaction id No Yes No groups multiple transaction records into a single processing unit. For example, in the enrollment process, the primary subscriber may have 3 dependents. Therefore, the same Tran Id of the 3 dependents is the same as the Tran Key and Tran Id of the subscriber Staging Area table. Tran Stage This identifies a No Yes No Num stage to the transaction process of the member of an employer group. For example, the various states for new enrollment transaction type (ENNW) are: “01 = new enrollment submitted by member” “02 = enrollment approved by employer” “03 = enrollment sent successfully to MCO” “06 = enrollment denied by employer” “07 = enrollment failed in delivery to MCO” “08 = enrollment denial exceeds 30 days from initial creation date” Tran Start This is the start No Yes No Date date/time of transaction process. Tran Status The status of this No Yes No transaction request. Tran Type This defines what No Yes No type of transaction is staged; i.e. enrollment, address change, etc. Employer Key Unique lookup key No No Yes that identifies this employer coverage based on a contract number with a MCO. MCO Key Unique managed care No No Yes identifier key. Member Key This identifies a No No Yes unique Member; currently based on Social Security Number and Date-Of- Birth. Practice Site This key uniquely No No Yes Key identifies a practice site for a provider. This practice details the MCO product that is provided by this doctor. Address1 Address Line 1 - i.e. No No No 111 Main Street Address2 Address Line 2 - i.e. No No No P.O. Box; Suite Number; etc. AMI Division A Division Number for No No No Num MCO plan in AMISYS. This field and/or AMI Group Number will point to a generic Sub Group Id. AMI DOD Amisys required Date No No No of Death. AMI Facility Amisys specific for No No No Cd HPHC Facility Code. AMI Group Num A Group Number for No No No its MCO plan in AMISYS. This field and/or AMI Division Number will point to a generic Sub Group Id. AMI PCP City Amisys requested city No No No of selected PCP. AMI PCP Id Amisys specific - No No No Provider Id. AMI Termdate Amisys specific No No No Termination date of subscriber/member. AMISYS Reject This field will store No No No Cd the AMISYS rejection code; if this member's record is rejected by the AMISYS system City The city name of the No No No effected member's address. COB Birthdate The birthday of the No No No subscriber to this Coordination of Benefits policy. COB Carrier The carrier insurance No No No Name company name for this coordination of benefits. COB Coverage The coverage type of No No No Type this policy number of the subscriber to this Coordination of Benefits policy. COB Effective The effective date of No No No Date this policy number of the subscriber to this Coordination of Benefits policy. COB First The first name of the No No No Name subscriber to this Coordination of Benefits policy. COB Last Name The last name of the No No No subscriber to this Coordination of Benefits policy. COB Policy The policy number of No No No Num the subscriber to this Coordination of Benefits policy. Country US postal country No No No code of the effected member's address. County The county name of No No No the effected member's address. Coverage Type This field details No No No the coverage type selected by the subscriber member: 1. individual 2. Family 3. 2Person . . . etc. Coverage Type The parameters to No No No Lookup Key LOOKUP table will be based on the type of healthcare coverage that the member is subscribing to: 1. I = Individual, 2. F = Family, 3. etc. Note that the various Coverage Types are different; depending on the Tier Type (in EMPLOYER_PLAN table) that is associated with Plan/Contract/Sub Group Id. Effective The effective start No No No Date date of this transaction; i.e. Enrollment date is future-dated. Enrollment process takes place usually 30-60 days before the actual start date. Email Address Email address of No No No member. Employer Plan This is the employer No No No Id plan id; it should uniquely identify the Employer to a Contract Id for a certain SubGroup (Group/Division) that it expect healthcare coverage from a MCO. Existing A ‘Y’es or ‘No’o flag No No No Patient Flg to indicate whether the member is an existing patient of the selected PCP. First Name First name of the No No No effected member of this transaction. Gender This is a single No No No character column; note that this is an optional field: 1. M = Male 2. F = Female Graduation Expected graduation No No No Date date of member from school. Hiredate The hiring date of No No No the subscriber member to the Employer group. Home Phone Long hand No No No Num representation of member's home phone number. For example, 800.555.1212 Language Cd The language code No No No that is preferred by this member. For example, 1. AS - American Sign Language 2. CA - Cantonese 3. EN - English 4. IT - Italian 5. Sp - Spanish . . . etc. Language Cd Contains the No No No Lookup Key appropriate Lookup Key in LOOKUP table for Language Cd. See definition of Language Cd field. Last Name Last name of the No No No effected member of this transaction. Middle Name Middle name of the No No No effected member of this transaction. Nickname A nickname to the No No No member's first name. Plan Cd This is the plan code No No No or name that is offered by the MCO. Plan Cd Contains the No No No LookupKey appropriate Lookup Key in LOOKUP table for Plan Cd. See definition of Plan Cd field. Prefix A prefix to the No No No member's name; i.e. Dr, Mr, Ms, etc. Relation Cd This field indicates No No No the relationship of member to the primary subscriber of plan. Current Relation Code recognized by HPHC are: 01 = Self 02 = Spouse 03 = Unmarried child under 19 04 = Unmarried stepchild under 19 05 = Unmarried fulltime student over 19 06 = Handicapped 07 = Ex- Spouse School City City code of school No No No that this full time student over 19 is attending. School Name Name of school that No No No this full time student over 19 is attending. School State State code of school No No No that this full time student over 19 is attending. School ZIP Postal zipcode of No No No school. School ZIP Long postal zipcode No No No Plus4 of school. Selected PCP Selected PCP for this No No No member; this can be as simple as the provider number. Semester End End date of school No No No Date semester of member. Semester Start date of school No No No Start Date semester for member. SSN Social Security No No No number of this member. State US postal state code No No No of the effected member's address. Student 19 This flag condition, No No No Flg ‘Y’es or ‘N’o, indicates whether the member information reflects that of a fulltime student over 19 and under the maximum student age (according to HPHC standard). Sub Group Id This is the Employer No No No group number that is known to the MCO. For example, a company may have a union and nonunion subgroups. Suffix A suffix to the No No No member's name; i.e. ESQ, II, etc. Tran End Date This is the start No No No date/time of transaction process. Work Phone User can place a Work No No No Num phone number in this field ZIP US postal zip code of No No No the effected member's address. ZIP Plus4 Longer version of US No No No postal zip code of the effected member's address. STAGING AUDIT This is an Audit Log Tran Key This is unique No Yes Yes for a specific identifier for this record; it will log particular Staging the WHO and WHEN and Area record. WHY a “Tran Stage Num” is reached within the Staging Area record. Modified By The identity of the No Yes No person updating a Staging transaction record to the new Stage Num; i.e. login user name. Modified Date The date/tamestamp to No Yes No when an update to the Staging transaction record to the new Stage Num. Tran Stage This identifies a No Yes No Num stage to the transaction process of the member of an employer group. Initial release supports: 1. Waiting For Employer Approval 2.successful to Connector Queue. Later releases should support the various stages that enrollment can be; i.e. all information except the PCP is inputted at one time. Comment This field can No No No capture any description that is attributed to a change to the stage of an enrollment. For example, the comments tied to a rejection of employee validation its employer. STAGING This table will Tran Key This is unique No Yes Yes DIGITAL ADDR contain other digital identifier for this addresses that is particular Staging related to this Area record. particular Staging Area record. For example, the STAGING AREA record contains a home, work, and email address for the primary HOME physical address. This table will allow for additional ones like: Cell, Pager, etc.; or different combinations like a Vacation Home phone number. Purpose Cd This identifies the No Yes No purpose of this address; such as: “1. PR = Practice Address” “2. HM = Home Address” “3. BL = Billing Address” “4. ML = Mailing Address” “5. WK = Work Address” Type Cd This code defined the No Yes No various types: “1. VC = Voice/Land phone” “2. CL = Cell phone” “3. PG = Pager” “4. EM = Email” “5. WB = Web Home Page” Valuel Contains initial No Yes No value associated with a type of digital address. For example - voice mail includes: 800.555.1212 or abc@foobar.com for Email type. Value2 This may be a second No No No value set to a specific type of digital address. For example - voice mail may include an extension part to the original phone number. Value3 This third value No No No association is for obscure elements like answer back string to a modem connect and/or future electronic requirements. STAGING This table will Tran Key This is unique No Yes Yes PHYSICAL ADDR contain other identifier for this physical addresses particular Staging that is related to Area record. this particular Staging Area record. For example, beside the primary Home address in the STAGING AREA record; this member may want to designate other types like: Work, Vacation, Practice, etc. Address1 Address line 1 No Yes No containing the typical information of: 123 Main Street City City name of physical No Yes No address, Country A recognized Postal No Yes No Country Code. County County name of No Yes No physical address. Purpose Cd This identifies the No Yes No purpose of this address; such as: “1. PR = Practice Address” “2. HM = Home Address” “3. BL = Billing Address” “4. ML = Mailing Address” “5. WK = Work Address” State State where physical No Yes No address is based. ZIP US based postal zip No Yes No code. Address2 Address line 2 No No No containing typical information regarding: P.O. Box; Suite#; Apt#; etc. ZIP Plus4 The longer version of No No No US-based postal zip code.

One of ordinary skill in the art will appreciate that the account structure described above and illustrated in FIGS. 13A-13C enables administrative transactions to be moved across health plans. Thus, as a user moves from one job to another, his or her member history can be taken along. As described above, the account provides a complete member history that is persistent across plan changes, employment changes, family history changes, and the like.

The administrative account allows members the opportunity to review and manage the many aspects of their personal care through a web browser. The account includes a record of the member's healthcare benefits throughout their life. Once enrolled, what was previously disparate data is now meaningful, actionable information. The system allows the user (member/patient/employee) to access their personal healthcare administrative record (e.g., personal profile, out-of-pocket expenses, utilization, etc.) and to use that information to increase their control over their healthcare experience. The account is portable, meaning that it will support a member's move to other employers or other health plans.

The account permits the member to view and update demographic information, insurance elections and medical information. The end user can create an online medical history for themselves and their dependents. The record can then be used to create health history reports for their physicians, schools and other institutions. As described above, the messaging module enables secure Web-based messaging among patients, providers, employers, and the MCO.

The present invention provides significant advantages. For the managed care organization, the enrollment data entry function is offloaded to members, which leads to quicker data entry and faster turnaround. The invention provides more accurate data due to online data entry by a member in a single place. Validation on data entry leads to fewer manual interventions, and lower cost per transaction due to reduced FTEs and reduced equipment costs. The invention provides for greater member loyalty due to ease of member enrollment and re-enrollment. For the member, the invention makes it easier and faster to re-enroll because data has been previously entered. The invention provides the member a greater degree of ownership as the data can be updated as often as necessary, and it provides a faster turnaround time due to elimination of paper. For the employer, there is less burden of processing paper-based forms. More accurate data is provided, and such data is always available via audit trails, activity reports and roster reports. Employers have lower costs per transaction as the system processes the transaction, not the employer. The invention provides the employers ease of administration when dealing with multiple MCOs. For the healthcare provider, the invention ensures more accurate and up-to-date data, because the member can view and update the data as necessary.

The invention is implemented in a server-side piece of code, as has been described. More generally, the inventive functionality is implemented in software executable in a processor, namely, as a set of instructions (program code) in a code module resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory, or downloaded via the Internet or other computer network.

In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.

As noted above, a given workstation and a server may communicate over the public Internet, an intranet, or any other computer network. If desired, given communications may take place over a secure connection. Thus, for example, a client may communicate with the server using a network security protocol, such as Netscape's Secure Socket Layer (SSL) protocol or the like.

A representative client is a personal computer, notebook computer, Internet appliance or pervasive computing device (e.g., a PDA or palm computer) that is Pentium-, PowerPC®- or RISC-based. The client includes an operating system, such as Microsoft Windows, Linux, Unix, Microsoft Windows CE, BeOS, PalmOS, and a login program. A representative server comprises a RISC- or Pentium-based processor, an operating system (e.g., NT, Unix, WebSphere, Linux, Apache, or the like) and, as needed, a trusted third party authentication service.

Having thus described our invention, what we claim as new and desire to secure by Letters Patent is set forth in the following claims. 

1. A computer system for use in a web-based managed care transaction system, the computer system comprising: a memory; and a set of linked data tables organized into a logical entity in the memory; wherein the set of linked data tables includes for each member: a master account table including account setup information for at least one of utilization and login actions for said web-based managed care transaction system; a member table including identity information for at least one member and their dependents; and a set of one or more member history tables associated with the member table, each member history table associated with a given employer plan, wherein said logical entity is persistent over changes to each member's changes within said employer plan; a plurality of linked tables representing a plurality of health providers, the plurality of tables including for each health provider in the plurality of health providers: a provider information table including identity information for the health provider; a provider specialty table identifying specialties practiced by the health provider; a site specialty table identifying specialties practiced by the healthcare provider at one or more sites; a hospital affiliation table identifying one or more hospitals affiliated with the health provider; and a provider affiliation table linked to the provider information table and said employer plan, the provider information table providing an intersection of the specialties in the provider specialty table and specialties allowed by said employer plan; wherein, for at least a given health provider from the plurality of health providers, the web-based managed care transaction system provides each member access to identity information for the given health provider, specialties practiced by the given health provider, specialties practiced by the healthcare provider at one or more sites, information related to one or more hospitals affiliated with the given health provider, and any specialties allowed by said employer plan; wherein the web-based managed care transaction system is adapted to enable, via the linked set of data tables, an administrative account to be moved across health plans of the at least one member and their dependents throughout their life; wherein the web-based managed care transaction system is adapted to allow the at least one member to review, manage, and update the administrative account via a web browser, the administrative account comprising a history of health plans including past and present health plans of the at least one member and their dependents; wherein the administrative account is owned by the at least one member; wherein the web-based managed care transaction system provides a personal healthcare network for each member, the personal healthcare network comprising the member, at least one employer, and at least one health provider; wherein the personal healthcare network facilitates secure communication of healthcare-related information therethrough; and wherein the web-based managed care transaction system limits communication of the member's healthcare-related information to selected parties of the personal healthcare network of the member.
 2. The computer system as described in claim 1 wherein the set of data tables includes an employer table having associated therewith a set of one or more employer plan tables.
 3. The computer system as described in claim 2 wherein a given employer plan table identifies a given employer plan.
 4. The computer system as described in claim 2 further including a managed care organization (MCO) table having associated therewith a set of one or more MCO product plan tables.
 5. The computer system as described in claim 4 wherein a given MCO product plan table has associated therewith the set of one or more employer plan tables.
 6. The computer system as described in claim 1 wherein a given member history table has associated therewith a set of one or more coordinated benefits tables.
 7. The computer system as described in claim 1 wherein a given member history table has associated therewith a set of one or more assigned primary care physician (PCP) tables.
 8. The computer system as described in claim 7 wherein an assigned PCP table has associated therewith a given provider affiliation table.
 9. The computer system as described in claim 1 wherein the provider information table includes a set of one or more provider staff tables.
 10. The computer system as described in claim 1 wherein the set of data tables includes a staging area table that includes data which tracks the member through various transaction events.
 11. A web-based managed care transaction system accessible over a computer network using a client browser, comprising: a transaction server; a database for storing a set of linked data tables organized into a persistent logical entity wherein said logical entity maintains data on each member in spite of status changes; wherein the set of linked data tables includes for each member: a master account table including account setup information for at least one of utilization and login actions for said web-based managed care transaction system; a member table including identity information for at least one member and their dependents; and a set of one or more member history tables associated with the member table, each member history table associated with a given employer plan; a plurality of linked tables representing a plurality of health providers, the plurality of tables including for each health provider in the plurality of health providers: a provider information table including identity information for the health provider; a provider specialty table identifying specialties practiced by the health provider; a site specialty table identifying specialties practiced by the healthcare provider at one or more sites; a hospital affiliation table identifying one or more hospitals affiliated with the health provider; and a provider affiliation table linked to the provider information table and said employer plan, the provider information table providing an intersection of the specialties in the provider specialty table and specialties allowed by said employer plan; wherein the web-based managed care transaction system is adapted to enable, via the linked set of data tables, an administrative account to be moved across health plans of the at least one member and their dependents throughout their life; wherein the web-based managed care transaction system is adapted to allow the at least one member to review, manage, and update the administrative account via the client browser, the administrative account comprising a history of health plans including past and present health plans of the at least one member and their dependents; wherein the administrative account is owned by the at least one member; wherein the web-based managed care transaction system provides a personal healthcare network for each member, the personal healthcare network comprising the member, at least one employer, and at least one health provider; wherein the personal healthcare network facilitates secure communication of healthcare-related information therethrough; and wherein the web-based managed care transaction system limits communication of the member's healthcare-related information to selected parties of the personal healthcare network of the member.
 12. A network-based managed care system comprising a network based server; at least one client machine on which a graphical user interface operates; a network based subsystem comprising: a multiplexer; a plurality of functional modules; a transaction processor; and a database wherein a logical entity retains data representative of users received healthcare within said database persistent across changes to a user's healthcare plan wherein the database includes: a master account table for retaining account setup information for at least one of utilization and login actions for said network-based managed care system; and a member table including identity information for at least one member and their dependents; a plurality of linked tables representing a plurality of health providers, the plurality of tables including for each health provider in the plurality of health providers: a provider information table including identity information for the health provider; a provider specialty table identifying specialties practiced by the health provider; a site specialty table identifying specialties practiced by the healthcare provider at one or more sites; a hospital affiliation table identifying one or more hospitals affiliated with the health provider; and a provider affiliation table linked to the provider information table and said employer plan, the provider information table providing an intersection of the specialties in the provider specialty table and specialties allowed by said employer plan; a managed care organization (MCO) subsystem interfaced to said transaction processor; wherein the network-based managed care system is adapted to enable, via the database, an administrative account to be moved across health plans of the at least one member and their dependents throughout their life; wherein the administrative account comprises a history of health plans including past and present health plans of the at least one member and their dependents; wherein the administrative account is owned by the at least one member; and wherein the network-based managed care transaction system provides a personal healthcare network for each member, the personal healthcare network comprising the member, at least one employer, and at least one health provider; wherein the personal healthcare network facilitates secure communication of healthcare-related information therethrough; and wherein the network-based managed care system limits communication of the member's healthcare-related information to selected parties of the personal healthcare network of the member.
 13. The network-based managed care system of claim 12 wherein said functional modules comprise: an enrollment module; billing module; messaging module; and inquiry module.
 14. The network-based managed care system of claim 12, wherein changes to a user's health plan occur as a user changes employment.
 15. The network-based managed care system of claim 12, wherein changes to a user's health plan occur as a user changes their healthcare plan.
 16. The network-based managed care system of claim 12 wherein the network comprises an Internet.
 17. The network-based care system of claim 12 wherein said database contains a historical record of care provided to said user.
 18. The network-based managed care system of claim 12 wherein said persistent logical entity comprises the administrative account.
 19. The network-based managed care system of claim 18 wherein said persistent logical entity spans a user's change in employment plans. 